home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-fopg-ositransition-00.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
46KB
|
1,581 lines
INTERNET OSI INTEGRATION, COEXISTENCE AND INTEROPERABILITY ISSUES
**********DRAFT**********
Version 0.1
R. Callon
R. Hagens
R. Nitzan
July 23, 1990
1. Status
This working document is a DRAFT intended for review. Com-
ments are encouraged.
2. Introduction
The intent of this document is to provide technical descrip-
tions of the issues involved in the integration of the Open
Systems Interconnect (OSI) protocols into the operational
networks which interconnect and comprise the "Internet". The
issues raised and solutions discussed are a result of the
Federal Networking Council (FNC) OSI Planning Group (FOPG).
The members of the FOPG represent several Federal Government
agencies such as the Department of Energy (DOE), the
National Science Foundation (NSF) the National Aeronautics
and Space Administration (NASA), the National Institute of
Standards and Technology (NIST) under the Department of Com-
merce, as well as University experts.
The Internet is composed of many networks. Some are funded
privately and some are funded by the U.S. Government, yet
all currently use the Transport Communications Protocol
(TCP)/Internet Protocol (IP) [2,3] and can communicate via
some physical connection point. Other networks use dif-
ferent protocols that physically connect, yet they are
essentially disjoint because the protocols they use do not
interoperate transparently with TCP/IP. As both non-TCP/IP
networks and the Internet begin to use OSI, the interconnec-
tivity expands and hence the size of the Internet. There-
fore, OSI integration into the non-TCP/IP networks that
interconnect, specifically the large DECnet* networks, is
considered as well.
*DECnet is a trade mark of Digital Equipment Corporation
It is recognized that there is a commitment to integrate OSI
DRAFT FOPG-OSI Spec July 23, 1990
into many networks that compose the Internet, however, it
must also be recognized that there is typically a higher
commitment to continue providing existing network services
to users. There are key pieces missing from the OSI infras-
tructure such as inter-domain routing, directory/name ser-
vice and network management. The missing components coupled
with the installed user base of TCP/IP will prevent OSI from
supplanting the TCP/IP protocol suite. As a result, in
addition to the integration of OSI, there will be coex-
istence and interoperability amongst OSI, TCP/IP and poten-
tially DECnet for the indefinite future.
Despite the current difficulties, there is large momentum
behind the OSI development, and it is anticipated to be in
wide use eventually. Some of the most optimistic specula-
tion has been that OSI will be in predominate use 5 years
from now, while the more pessimistic speculation is that it
will take another 10 years.
The integration and transition of any new protocols into a
large established network base will require adjustments or
fine tuning to the protocols themselves as well as to how
they are used. This is a normal expectation for changes of
this magnitude. Throughout this paper an attempt is made to
identify the issues and potential problems that will arise
as the new OSI protocols are integrated. This is considered
an important part of the initial planning stage.
2.1. Scope and Objectives
Each administration responsible for their networks may have
their own policy and guidelines for the integration of OSI.
Due to the diversity of existing administrations, networks,
and users, it is nearly impossible to generate a common OSI
integration plan. Administrations serving user communities
with different requirements may require different solutions
that are specific to their particular needs.
Therefore, this document does not contain "The OSI Integra-
tion Plan". Rather, it attempts to address the various
issues and scenarios that may arise in the general case
i.e., coexistence and interoperability between TCP/IP and
OSI.
The objectives of this paper are to provide:
+ A compendium of coexistence and interoperability
issues.
+ A summary of solutions to the various coexistence and
interoperability issues. This includes an analysis of
Page 2
DRAFT FOPG-OSI Spec July 23, 1990
each solution as well as an indication of issues that
require work and are currently lacking resources.
Page 3
DRAFT FOPG-OSI Spec July 23, 1990
3. THE CURRENT AND FUTURE INTERNET
It is important to understand the state of the current
TCP/IP Internet while analyzing the subsequent issues. The
current model of the evolving Internet is based around three
components: high speed backbones, large regional networks,
and local site networks. The local area networks connect to
regional networks. In turn, the regional networks connect to
the high speed backbones. There are variations, e.g., some
local sites have direct high speed backbone connections, and
many regionals interconnect to each other through "backdoor
routes". In fact, the number of connections is increasing
resulting in a meshed environment, even though there have
been successful attempts to consolidate links.
The backbones are government funded networks, where some
have multi-protocol requirements. For example, both DOE and
NASA backbones have multi-protocol mission support require-
ments for TCP/IP and DECnet. Most of the backbones are
planning to start carrying operational ISO 8473 [] traffic
in either 1990 or early 1991.
Regional networks, though originally funded by the govern-
ment, are tending to become privately operated. Regionals
will likely provide operational ISO 8473 forwarding capabil-
ities as user requirements become apparent.
Most OSI software (including a full OSI stack) can operate
on a local area network. However, a lack of user require-
ments for operational OSI software has slowed the deployment
of OSI on local area networks.
4. Looking Towards OSI
Rapid transition from TCP/IP to OSI is not likely to occur.
Rather, it is anticipated that an extended period will take
place during which both protocol suites will be in
widespread use. This will require both coexistence and
interoperability between the two protocol suites.
4.1. Coexistence
Coexistence among protocol suites occurs when separate pro-
tocols run simultaneously on the same network. Coexistence
options vary from running dual protocol stacks to operating
physically separate networks.
Physically separate networks are usually not practical since
they require separate circuits, devices, routers and
resources in general. This is (typically) incongruous with
the strong cost incentive to share physical resources.
Page 4
DRAFT FOPG-OSI Spec July 23, 1990
Dual protocol stacks can run in parallel in an end system
and/or an intermediate system. Dual protocol (or multiproto-
col in general) schemes are usually cost effective because
they allow two or more software stacks to share the same
physical resources. However, this may lead to an increase in
the number of resources required by the machine and in the
complexity of the operational management of two essentially
separate networks.
4.2. Interoperability
Interoperability becomes an issue when the two end points of
a communication path do not use the same protocol suite. In
this situation, a conversion mechanism is required to bridge
the gap between the two protocols.
Interoperability issues arise at many layers. For example,
two machines may have the same application protocol suite,
but have incompatible network layer protocols. On the other
hand, two machines may share a compatible network layer pro-
tocol, but have incompatible applications.
Interoperability may require that the user be aware of the
presence of two protocol suites. In the long run, this is
unacceptable on a large scale.
4.3. Mixed Protocol Environment
In a mixed environment, more than one protocol stack is
used. The stack itself may be mixed, e.g., TCP/IP lower
layers and OSI upper layers. It may also be an environment
where a pure protocol stack is trying to communicate with a
mixed or different protocol stack, e.g., an OSI end system
trying to communicate with another end system running OSI
applications with TCP/IP lower layers.
5. Status of Issues by Protocol Layer
The following sections, categorized by protocol layer, dis-
cuss OSI and TCP/IP coexistence and interoperability.
5.1. Physical Layer
There are no known physical layer issues that need to be
resolved.
Page 5
DRAFT FOPG-OSI Spec July 23, 1990
5.2. Data Link Layer
The Government OSI Profile (GOSIP) Version 2.0 [20] speci-
fies 3 data link layer protocols: 1) High Level Data Link
Communication (HDLC) Link Access Procedure B (LAP B), in
conjunction with X.25 (ISO 7776) and Pt-Pt subnetworks; 2)
ISO 8802/2 (LLC 1) in conjunction with ISO 8802/3, ISO
8802/4, or ISO 8802/5; and 3) Q.921 for operation on the
ISDN D channel and ISO 7776 (LAP B) for operation on ISDN B
channels.
The Internet standard data link layer is the Point to Point
Protocol (PPP) [22].
5.2.1. Coexistence Issue: OSI and IP over HDLC
Status: resolved.
OSI and IP packets may be distinguished on an HDLC link by
examining the Network Layer Protocol ID (NLPID) field of the
HDLC or X.25 header. NLIPDs have been assigned for IP and
ISO 8473. This allows both protocols to run over HDLC or
over HDLC/X.25.
5.2.2. Coexistence Issue: OSI and IP over 802.x
Status: resolved.
OSI and IP packets may be distinguished on 802.2 links by
examining the Destination Service Access Point (DSAP) field
in the 802.2 header. DSAP values have been assigned for OSI
packets as well as IP packets.
5.2.3. Coexistence Issue: OSI and IP over PPP
Status: work and resources needed.
PPP indicates what type of protocol follows in a field
within the PPP header. Currently a value is defined indi-
cating IP as the next layer protocol. There is some minimal
work needed to specify a next level protocol value indicat-
ing ISO 8473.
5.3. Network Layer
Several pieces of the OSI network layer such as the specifi-
cation of CLNP, and the ES-IS routing protocol are complete
and provide the transmission of OSI network layer data over
local area networks. However, for the network layer to be
used on a wide scale, IS-IS routing protocols must be
Page 6
DRAFT FOPG-OSI Spec July 23, 1990
deployed.
5.3.1. Operational Issue: OSI Intra-domain IS-IS protocol
Status: in progress.
The IS-IS intra-domain dynamic routing protocol [25] is
currently a Draft Proposal in the ISO/IEC standards organi-
zations. IS-IS for ISO 8473 is being progressed rapidly,
and is anticipated to become an International Standard in
1991.
5.3.2. Coexistence Issue: Integrated or Parallel Intra-
domain protocols
Status: work and resources needed.
Widespread deployment of both IP and CLNP require the opera-
tion of a routing protocol. Two basic approaches to this
problem have been identified. In the integrated approach,a
single routing protocol is deployed which supports the rout-
ing of both IP and CLNP packets. In the Parallel approach,
two distinct, independent protocols are operated.
A detailed analysis of these two approaches is required.
This analysis must address the advantages and disadvantages
of each approach and recommend the conditions when each
approach is favorable.
5.3.3. Operational Issue: Intra-domain IS-IS for Dual Use
Status: in progress.
The IETF IS-IS working group is working on integrated rout-
ing for both IP and ISO 8473. There is an Internet Draft
RFC which is expected to become an RFC in mid 1990.
5.3.4. Operational Issue: Inter-domain Routing
Status: in progress, resources needed.
There is a draft specification of an Inter-Domain Routing
Protocol (IDRP) for consideration as the U.S. contribution
to the ISO/IEC standards committees. The previous efforts
by ECMA and the development of the Boarder Router Protocol
(BRP) contributed to form the basis for this IDRP.
There is also an Internet effort for inter-domain routing
based on source routing. It has the added feature of policy
Page 7
DRAFT FOPG-OSI Spec July 23, 1990
based routing. It is not clear how these two efforts can
relate to each other.
Static, manually updated tables will be used in the short
term for inter-domain routing in an ISO 8473 Internet. This
will be required until there is either an International
Standard for an IDRP or until an interim IDRP is agreed
upon, implemented and commercially available.
Static tables are unacceptable on a large scale because of
the requirement for human intervention to re-route traffic
in the event of link failure, and because of the extra bur-
den caused in maintaining large routing tables manually.
It is expected that the lack of an IDRP will greatly reduce
the deployment of the OSI Connectionless Network Service
(CLNS). Thus, there is an urgent requirement for an interim
IDRP agreement and implementation.
5.3.5. Operational Issue: NSAP Format
Status: in progress.
Structure for the Domain Specific Part (DSP) of the Network
Service Access Point (NSAP) address has been defined in
GOSIP Version 2.0.
The GOSIP format is solidified pending GOSIP Version 2.0
final release. (GOSIP Version 1.0 [] will have errata that
specifies the GOSIP Version 2.0 NASAP address format.) The
lower portion of the DSP has structure that is compatible
with the IS-IS intra-domain routing protocol requirements.
The GOSIP Version 2.0 format should be used for those
administrations which are getting their address assignments
from the US government address space.
ANSI also assigns NSAPS with a format that has no structure
imposed on the DSP. These addresses will be used by non-
government networks. A common structure such as defined in
GOSIP Version 2.0 should be adopted and used.
5.3.6. Operational Issue: NSAP Guidelines
Status: in progress.
The NSAP working group in the IETF is working on guidelines
regarding OSI addressing. Results may be submitted to the
OSI Implementors Workshop and become part of the GOSIP
Users' Guide for GOSIP Version 2.0.
See Appendix ? for details of these guidelines.
Page 8
DRAFT FOPG-OSI Spec July 23, 1990
5.3.7. Operational Issue: ISO 8473 Echo
Status: in progress.
The IETF has completed work on an ISO 8473 echo function
[23]. It must be supported in order to get it through the
ISO/IEC standards committees. This Protocol is considered a
vital tool for simple network operational support.
5.3.8. Coexistence Issue: CLNS/CONS Interoperability
Status: in progress, resources needed.
It is anticipated that there will be wide spread use of the
connection-less and connection-oriented network services. A
solution to this problem must be reached. An ISO technical
report [21] specifies a possible solution.
5.4. Transport Layer
Transport relays (or gateways or bridges) have been proposed
as both a coexistence and an interoperation strategy. This
is discussed in a later section.
5.5. Session and Presentation
No work is needed. The Session and Presentation Layers for
the OSI suite operate independently of the TCP/IP suite.
5.6. Electronic Mail
There are several issues relating to the operation of X.400
(the OSI electronic mail system) and coexistence of X.400
and RFC 822 mail systems.
5.6.1. Operational Issue: X.400 routing
Status: in progress.
There is some work in the NIST X.400 SIG on routing of X.400
messages between MTAs. <TODO: get info from stef on this>
5.6.2. Interoperation Issue: An X.400/RFC 822 gateway
Status: in progress.
The specification of an RFC 822/X.400 gateway is RFC 987/RFC
Page 9
DRAFT FOPG-OSI Spec July 23, 1990
1148
5.6.3. Operational Issue: Structure of X.400 addresses
Status: in progress, resources needed.
In order to deploy X.400 in the Internet, Internet X.400
users must be given X.400 addresses. How should these
addresses be constructed? The two basic choices are to con-
struct X.400 addresses based upon X.400 naming guidelines,
or to construct X.400 addresses based upon existing RFC 822
addresses.
In general, the recommended practice is to create X.400
addresses that are meaningful to the organization (and
without regard to any preassigned RFC 822 addresses).
5.6.4. Operational Issue: Use of the PRMD/ADMD field
Status: needs work, resources needed.
The US must make a policy decision on the use of blank ADMD
fields and the registration of PRMD names. Lack of a
national policy regarding these attributes will lead to
chaos as government, private, and public X.400 networks
become interconnected.
An initiative with the US State Department (Study Groups A-
D) has been formed to oversee the creation of the proper
committee to study this issue. (See Stef).
5.6.5. Interoperation Issue: Identification of the users
Status: in progress, resources needed.
A small but growing population of users in the U.S. Internet
are starting to use X.400. These X.400 users must be
addressable by RFC822 mail users. RFC987 and RFC1148 gate-
ways exist that allow translation and mapping between X.400
and RFC822 messages. One strategy that European countries
have taken is to define MX records that appear to be normal
RFC822 addresses, but which actually point to an RFC987/1148
gateway to translate messages into the X.400 world. This
gives X.400 users an Internet-style address that is concise,
easy to type, and consistent with tradition Internet
addresses.
Another strategy is to embed the X.400 address within the
RFC 822 syntax.
Page 10
DRAFT FOPG-OSI Spec July 23, 1990
Looking toward the future, it would be delightful if a user
could use a common, natural address syntax for all mail,
whether sent to an X.400 system, or to an RFC 822 system.
The X.500 directory is a key to this situation.
A strategy for the Internet must be discussed and docu-
mented.
5.6.6. Operational Issue: 987/1148 mapping table support
Status: in progress, resources needed.
Complex operation of an 987/1148 gateway requires the global
distribution of static address mapping information. The
current practice of manual distribution will not scale. An
experimental use of the DNS to store the mapping information
has been undertaken at the University of Wisconsin. Storage
of the mapping information in the DNS allows the information
to be stored in a distributed manner.
The use of the DNS to support RFC 987/1148 mapping informa-
tion must be reviewed and documented.
5.6.7. Operational Issue: 987/1148 gateway security
Status: work and resources needed.
There is considerable work in both the Internet (RFC 822)
community and the ISO (X.400) community on security for
electronic mail. It does not appear that there has been any
serious study of how a mail gateway affects the two security
models.
5.7. Virtual Terminal Protocol
Status: This section needs to be reviewed by a VTP expert
The Virtual Terminal Protocol VTP is the OSI version of
remote login. There has been a VTP profile written, that is
similar to the Internet TELNET protocol. There currently is
an implementation of this, where both the OSI VTP and the
Internet TELNET can run in the same host. This results in an
application relay running directly in the host, thereby by-
passing the added complication of determining where the
application gateway is located. A user can login to the
host via either VTP or TELNET and from there perform addi-
tional remote logins to other machines with either TELNET or
VTP.
There is also another profile which is more in tune with the
Page 11
DRAFT FOPG-OSI Spec July 23, 1990
International Telegraph and Telephone Consultative Committee
(CCITT) recommendation for the terminal standard X.3, X.28,
and X.29. The functionality is very similar to TELNET. In
addition, there is a third generic VTP profile.
In regards to the user locating the application gateway, one
solution is to require a two step login. The user expli-
citly logs into the application gateway via VTP or TELNET
and from there uses TELNET or VTP to get to another destina-
tion.
5.8. File Transfer
Status: This section needs to be reviewed by a FTAM expert
There is <??> work being done on an application gateway
between the OSI File Transfer, Access and Management (FTAM)
[] and the Internet File Transfer Protocol (FTP) [].
As in the VTP and TELNET scenario, it is feasible for a user
use a two step approach. For file transfer it is a burden
since multiple file transfers may be executed in a login
session as well as in application software.
6. Issues Spanning Multiple Layers
6.1. Directory Services
6.1.1. Operational Issue: organization of the name space
Status: work and resources needed.
Currently there is work being done in the X.500 OSI Imple-
mentors Workshop. In addition, an IETF X.500 working group
has been started.
6.1.2. Coexistence Issue: Multi-Stack protocol selection
Status: work and resources needed.
A dual stack end system must select which protocol stack to
use when trying to get to a specific remote location via
directory service query. Thus, the directory system must
contain information to aid in protocol stack selection. In
addition, the directory must provide some aid in the inden-
tification a gateway if the two end systems do not share a
common protocol stack.
This topic is in the scope of the IETF X.500 working group.
Page 12
DRAFT FOPG-OSI Spec July 23, 1990
6.1.3. Coexistence Issue: Interoperability between X.500
and the Internet DNS
Status: work and resources needed.
This topic is in the scope of the IETF X.500 working group.
6.2. Security, Access Control and Authentication
Status: work and resources needed.
Multi-protocol secuity issues have not been studied. How-
ever, it is likely that multi-stack interoperability prob-
lems will result if the security for IP-only environments
and security for OSI-only environments is not integrated.
Coordination between the IP and OSI security efforts is
necessary to ensure security when trying to interoperate
between the two electronic mail services.
6.3. Network Management
Status: dazed and confused.
The IETF is defining how to use the Simple Network Manage-
ment Protocol (SNMP) to manage pure OSI systems. This is
likely to lead to confusion.
This section needs review by an expert in network manage-
ment.
6.4. Summary of the Status
The following table summarizes the status of the work at
various levels.
Page 13
DRAFT FOPG-OSI Spec July 23, 1990
Layer/Issue Current Responsible
Status Group/Person
Datalink
+ OSI & IP over Ethernet/802.2,3,4 DONE
+ OSI & IP over HDLC/LAPB DONE
+ OSI & IP over X.25 DONE
+ OSI & IP over PPP WORK NEEDED IETF WG
Routing
+ IS-IS for OSI only IN PROGRESS ANSI/ISO
+ IS-IS for OSI and IP (dual) EXPERIMENTALIS-IS WG
+ Inter-Domain Routing IN PROGRESS ANSI
+ Coexistence analysis WORK NEEDED IETF
Network
+ NSAP address format DONE
+ NSAP guidelines IN PROGRESS NSAP WG/NIST
+ ISO 8473 Echo IN PROGRESS ANSI/ISO
+ CLNS/CONS Interoperating IN PROGRESS ANSI/ISO
Electronic mail
+ X.400 Routing IN PROGRESS NIST X.400 SIG
+ RFC 822/X.400 Gateway EXPERIMENTALIETF
+ O/R Address Format WORK NEEDED
+ PRMD/ADMD Field WORK NEEDED
+ User Identification IN PROGRESS IETF
+ 987/1148 support IN PROGRESS IETF
+ Gateway Security WORK NEEDED
Virtual Terminal
File Transfer
Directory Services
+ Name space IN PROGRESS NIST/IETF
+ Multi-stack query WORK NEEDED IETF X.500 WG
+ X.500/DNS interoperation WORK NEEDED IETF X.500 WG
Security and Access Control
+ Dual environments WORK NEEDED
Network Management
+ CMIP/SNMP WORK NEEDED
Mixed Stack
+ ISODE ?
7. Strategies and Scenarios
In the follow sections, various coexistence scenarios are
examined. Each scenario is defined by type of the source
and destination protocol stack. In order to keep the combi-
nations under control, the following types of protocol
stacks are defined:
Page 14
DRAFT FOPG-OSI Spec July 23, 1990
Network Layer Application Suite
TCP/IP OSI
TCP/IP Internet
CLNS-OSI OSI
CONS-OSI OSI
The combination of TCP/IP Network Layers and OSI applica-
tions is accomplished according to RFC 1006 [24]. This
mechanism operates the TP0 protocol, along with a simple
packetization protocol on top of the TCP/IP, which is used
as a connection-oriented network service. With the RFC 1006
approach, OSI applications can establish a connection over
any TCP/IP network.
The first stack definition (TCP/IP Network Layers, OSI
Applications) includes both an RFC 1006 mixed stack and a
pure stack OSI system connected to an OSI LAN (where the LAN
is surrounded by TCP/IP-only capable routers).
Of the possible 16 possible combinations of source and des-
tination pairs, some are non-issues since they do not result
in a mixed stack environment, such as a TCP/IP host communi-
cating with another TCP/IP host over an IP network. The
important cases are:
Case Source Destination
Stack Stack
1 [TCP/IP Net, Internet Appl] [TCP/IP Net, OSI Appl]
2 [TCP/IP Net, Internet Appl] [CLNS-OSI Net, OSI Appl]
3 [TCP/IP Net, OSI Appl] [CLNS-OSI Net, OSI Appl]
4 [TCP/IP Net, OSI Appl] [CONS-OSI Net, OSI Appl]
5 [CLNS-OSI Net, OSI Appl] [CONS-OSI Net, OSI Appl]
These are only the simplest of cases. More complicated tran-
sit cases may arise where different networks are in the mid-
dle. These cases are discussed in a later section.
7.1. Case 1
This case requires an application layer gateway.
Page 15
DRAFT FOPG-OSI Spec July 23, 1990
7.2. Case 2
Case two requires an application gateway with the added bur-
den of an interoperability problem at the network layer. The
most likely solution to this problem requires an application
gateway with two network layer protocols (IP Net and CLNS-
OSI Net).
ADVANTAGES:
o No modification to the end system software
DISADVANTAGES:
o Performance degradation, especially apparent in interac-
tive mode.
o Locating the application gateway is an issue for the end
system.
o Functionality loss if one application has greater capabil-
ities and hence do not map to the other application.
7.3. Case 3
Case three can be solved with a transport relay (or network
layer encapsulation if the [TCP/IP Net, OSI App] really is a
pure OSI system isolated in a TCP/IP internet).
7.3.1. A Transport Relay
Transport relaying can be used when two end systems are run-
ning common applications and the lower layer protocols (up
to and including the transport layer) are different. The
transport relay converts one lower layer stack to another
stack, mapping relevant information between the protocols.
All traffic must explicitly go through a transport service
relay at the boundary where the underlying network services
differ. There are several cases that need this type of
capability. For example, an end system running TCP/IP lower
layers and OSI applications communicating with an end system
running OSI lower layers (CONS or CLNS) and OSI applica-
tions.
ADVANTAGES:
o Interoperability between OSI upper layers over a TCP/IP
lower layer network.
o Complete transparency to the OSI upper layers
Page 16
DRAFT FOPG-OSI Spec July 23, 1990
DISADVANTAGES:
o The end system must modify its transport service.
o Locating the relay is an issue that requires static tables
or a new protocol.
o End-to-end packet encryption incurs a security compromise.
This is because the encryption algorithm must be re-computed
in the relay which requires knowledge of the encryption key.
A relay having knowledge of an encryption key is the secu-
rity risk.
o End-to-end guarantee of non-corrupted data is compromised.
A packet having a data error while in the transport relay
will get through without notice since the checksum is recom-
puted using a different checksum algorithm.
7.3.2. Network Layer Encapsulation
An ISO 8473 packet may be encapsulated in an IP packet.
Specifically, the ISO 8473 protocol runs above the IP layer.
Once encapsulated, the ISO 8473 portion is treated as data
by the IP layer and is indistinguishable from any other IP
packet. The encapsulated ISO 8473 packet may be forwarded
through any IP router. When the IP portion is removed (de-
encapsulated), leaving the ISO 8473 packet intact, it
appears to the OSI network layer as if it has traversed a
single subnetwork.
This scheme is useful when an isolated CLNS LAN must
traverse a TCP/IP based internetwork on its way to an CLNS
based destination. This scheme is most efficient when only
one system (an IS) on the LAN is allowed to
encapsulate/decapsulate.
ADVANTAGES:
o Interoperability between OSI upper layers over a TCP/IP
lower layer network.
o Complete transparency to the OSI upper layers
o No modification to the end system software, unless the end
system is the encapsulator.
DISADVANTAGES:
o Deriving encapsulators' and de-encapsulators' IP
addresses from NSAP addresses requires static tables or a
new protocol.
Page 17
DRAFT FOPG-OSI Spec July 23, 1990
7.4. Case 4
Case four can be solved with a transport relay.
7.5. Case 5
Case five can be solved with a transport relay.
7.6. More complicated transit situations
In all of the solutions that facilitate interoperability and
coexistence, there is a question as to what the result will
be when the situation becomes complex. For example, con-
sider two end systems where the path between them transits
several networks, some OSI (both X.25 and ISO 8473) and some
TCP/IP. At what point does the solution break? How many
cases is it reasonable to analyze?
Here are several:
Case 6: [OSI Net, OSI Appl] <-> [TCP/IP TRANSIT] <-> [OSI Net, OSI Appl]
Case 7: [TCP/IP Net, Internet Appl] <-> [OSI TRANSIT] <-> [OSI Net, OSI Appl]
Case 8: [TCP/IP Net, Internet Appl] <-> [OSI TRANSIT] <-> [TCP/IP Net, OSI Appl
]
Case 9: [TCP/IP Net, OSI Appl] <-> [OSI TRANSIT] <-> [TCP/IP TRANSIT] <-->
[OSI Net, OSI Appl]
Case 6 is best handled by network encapsulation. Case 7
requires an application gateway at the edge of the OSI TRAN-
SIT network. Case 8 requires both an application gateway and
network encapsulation (IP within CLNP). In case 9, if the
[TCP/IP Net, OSI Appl] is really an isolated pure OSI stack,
then encapsulation across the TCP/IP TRANSIT is all that is
required. If the [TCP/IP Net, OSI Appl] is an RFC 1006 host,
then both IP encapsulation and a transport service bridge
may be required.
These situations can generally be broken down by the follow-
ing guidelines. If the application changes, then an appli-
cation gateway is required. When an application gateway is
required and the network service is incompatible, it is best
to locate the application gateway at the point where the
network service changes.
If an application gateway is not required then the network
service is the primary consideration. If the network service
Page 18
DRAFT FOPG-OSI Spec July 23, 1990
is the same at both ends of the connection, then it is best
to use network layer encapsulation. Otherwise, if the net-
work service is different at both ends, a transport relay is
required.
8. CURRENT STATUS OF OSI IN THE INTERNET
8.1. NATIONAL BACKBONES
Most of the national backbone networks plan to start provid-
ing limited Connectionless Network Service (CLNS) in late
1990 or early 1991. Some of the agency backbones are
upgrading DECnet Phase IV to DECnet Phase V, which includes
ISO 8473 end to end service.
There are two issues to resolve before most of the backbones
can provide operational ISO 8473: (1) routing domain boun-
dary designation and (2) address registration and dissemina-
tion. Until IS-IS dynamic intra-domain routing, network
management and directory service is available commercially,
limited operational capabilities can be expected for some
networks.
Page 19
DRAFT FOPG-OSI Spec July 23, 1990
9. APPENDIX A
9.1. DEFINITION OF ACRONYMS
ADMD Administrative Management Domain
AFI Authority and Format Identifier
BRP Boarder Router Protocol
CCITT International Telegraph and Telephone Consultative Committee
CLNP Connectionless Network-layer Protocol
CLNS Connectionless Network Service
CMIP Common Management Information Protocol
CONS Connection-Oriented Network Service
DCC Data Country Code
DECnet Digital Equipment Corporation Network
DNS Distributed Name Service
DSP Domain Specific Part
DOE Department of Energy
ECMA European ??
ES End System
FNC Federal Networking Council
FOPG Federal Networking Council OSI Planning Group
FTAM File Transfer, Access and Management
FTP File Transfer Protocol
GOSIP Government Open System Interconnect Profile
HDLC High level Data Link Control
IDRP Inter Domain Routing Protocol
IEC International Electrotechnical Committee
IETF Internet Engineering Task Force
IP Internet Protocol
ISO International Organization for Standards
NASA National Aeronautics and Space Administration
NIST National Institute of Standards and Technology
NSAP Network Service Access Point
OSI Open Systems Interconnection
OSPF Open Shortest Path First
PPP Point-to-Point Protocol
RFC Request For Comment
SNMP Simple Network Management Protocol
TCP Transport Communications Protocol
VTP Virtual Terminal Protocol
Page 20
DRAFT FOPG-OSI Spec July 23, 1990
10. REFERENCES
[1] "U.S. Government Open Systems Interconnections Profile".
August 1988. U.S. Federal Information Processing Standards
Publication 146. Version 1.
[2] J.B Postel, "Internet Protocol", Request For Comment
#791, September 1981. DDN Network Information Center, SRI
International.
[3] J.B Postel, "Transmission Control Protocol", Request For
Comment #793, September 1981.
[4] ISO 7498 "Basic Reference Model for Open Systems Inter-
connection"
[5] ISO/IEC 8473, Information Processing Systems, "Protocol
for Providing the Connectionless-mode Network Service and
Provision of Underlying Service". May, 1987.
[6] M.T. Rose, D.E. Case, "ISO Transport on Top of the TCP",
Request For Comment #1006, 1987 June. DDN Network Informa-
tion Center, SRI International.
[7] ISO/IEC 8571-1 Information Processing Systems - "File
Transfer, Access and Management Part 1: General Introduc-
tion". April, 1988.
[8] J.B. Postel, J.K. Reynolds, "File Transfer Protocol",
Request For Comment #959, 1985 October. DDN Network Informa-
tion Center, SRI International.
[9] CCITT Recommendation X.400 (Red Book, 1984), "Message
Handling Systems: Systems Model-Service Elements".
[10] J.B. Postel, "Simple Mail Transfer Protocol", Request
For Comment #821, August 1982. DDN Network Information
Center, SRI International.
[11] Information Processing Systems, "Virtual Terminal Ser-
vice: Basic Class", August, 1987. Draft International Stan-
dard 9040.
[12] J.B. Postel, J.K. Reynolds, "Telnet Protocol Specifica-
tion", May 1983. DDN Network Information Center, SRI Inter-
national.
[13] Marshall T. Rose. "The Open Book - A Practical Perspec-
tive on OSI". Prentice Hall, Englewoods Cliffs, 1990. ISBN
0-13-643016-3.
[14] Tim Boland. "Government Open Systems Interconnection
Profile Users' Guide". August, 1989. NIST Special
Page 21
DRAFT FOPG-OSI Spec July 23, 1990
Publication 500-163.
[15] "Digital Network Architecture (Phase V)". September,
1987. Digital Equipment Corporation. Maynard, Massachusetts
[16] ISO/IEC JTC 1/SC6/N4945:1989, Telecommunications and
Information "Exchange Between Systems, Intra-Domain IS-IS
Routeing Protocol"
[17] J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin, "Sim-
ple Network Management Protocol", Request For Comment #1098,
April 1989. DDN Network Information Center, SRI Interna-
tional.
[18] J. Moy, "Open Shortest Path First", Request For Comment
#1131, 1989 October. DDN Network Information Center, SRI
International.
[19] "Stable Implementation Agreements for Open Systems
Interconnection Protocols", Version 2 Edition 4. September,
1989. NIST Special Publication 500-162.
[20] "U.S. Government Open Systems Interconnections Pro-
file". July 1988. U.S. Federal Information Processing Stan-
dards Publication 146. Draft Version 2.
[21] ISO/DTR 10172: Information Processing Systems - Data
Communications - Network/Transport Protocol Interworking
Specification.
[22] "Point to Point Protocol", Request For Comment #?,
1989. DDN Network Information Center, SRI International
[23] RFC 1139
[24] RFC 1006
[25] ISO/DP 10589: Information Processing Systems - Data
Communications - Intermediate system to Intermediate system
Intra-Domain routing exchange protocol for use in Conjunc-
tion with the Protocol for providing the COnnectionless-mode
Network Service (ISO 8473).
[] NLPID
Page 22
DRAFT FOPG-OSI Spec July 23, 1990
TABLE OF CONTENTS
Section 1 Status ...................................... 1
Section 2 Introduction ................................ 1
Section 2.1 Scope and Objectives ...................... 2
Section 3 THE CURRENT AND FUTURE INTERNET ............. 4
Section 4 Looking Towards OSI ......................... 4
Section 4.1 Coexistence ............................... 4
Section 4.2 Interoperability .......................... 5
Section 4.3 Mixed Protocol Environment ................ 5
Section 5 Status of Issues by Protocol Layer .......... 5
Section 5.1 Physical Layer ............................ 5
Section 5.2 Data Link Layer ........................... 6
Section 5.2.1 Coexistence Issue: OSI and IP over
HDLC ............................................. 6
Section 5.2.2 Coexistence Issue: OSI and IP over
802.x ............................................ 6
Section 5.2.3 Coexistence Issue: OSI and IP over PPP
.................................................. 6
Section 5.3 Network Layer ............................. 6
Section 5.3.1 Operational Issue: OSI Intra-domain
IS-IS protocol ................................... 7
Section 5.3.2 Coexistence Issue: Integrated or
Parallel Intra-domain protocols .................. 7
Section 5.3.3 Operational Issue: Intra-domain IS-IS
for Dual Use ..................................... 7
Section 5.3.4 Operational Issue: Inter-domain
Routing .......................................... 7
Section 5.3.5 Operational Issue: NSAP Format .......... 8
Section 5.3.6 Operational Issue: NSAP Guidelines ...... 8
Section 5.3.7 Operational Issue: ISO 8473 Echo ........ 9
Section 5.3.8 Coexistence Issue: CLNS/CONS
Interoperability ................................. 9
Section 5.4 Transport Layer ........................... 9
Section 5.5 Session and Presentation .................. 9
Section 5.6 Electronic Mail ........................... 9
Section 5.6.1 Operational Issue: X.400 routing ........ 9
Section 5.6.2 Interoperation Issue: An X.400/RFC 822
gateway .......................................... 9
Section 5.6.3 Operational Issue: Structure of X.400
addresses ........................................ 10
Section 5.6.4 Operational Issue: Use of the
PRMD/ADMD field .................................. 10
Section 5.6.5 Interoperation Issue: Identification
of the users ..................................... 10
Section 5.6.6 Operational Issue: 987/1148 mapping
table support .................................... 11
Section 5.6.7 Operational Issue: 987/1148 gateway
security ......................................... 11
Section 5.7 Virtual Terminal Protocol ................. 11
Section 5.8 File Transfer ............................. 12
Section 6 Issues Spanning Multiple Layers ............. 12
Section 6.1 Directory Services ........................ 12
Page 23
DRAFT FOPG-OSI Spec July 23, 1990
Section 6.1.1 Operational Issue: organization of the
name space ....................................... 12
Section 6.1.2 Coexistence Issue: Multi-Stack
protocol selection ............................... 12
Section 6.1.3 Coexistence Issue: Interoperability
between X.500 and the Internet DNS ............... 13
Section 6.2 Security, Access Control and
Authentication ................................... 13
Section 6.3 Network Management ........................ 13
Section 6.4 Summary of the Status ..................... 13
Section 7 Strategies and Scenarios .................... 14
Section 7.1 Case 1 .................................... 15
Section 7.2 Case 2 .................................... 16
Section 7.3 Case 3 .................................... 16
Section 7.3.1 A Transport Relay ....................... 16
Section 7.3.2 Network Layer Encapsulation ............. 17
Section 7.4 Case 4 .................................... 18
Section 7.5 Case 5 .................................... 18
Section 7.6 More complicated transit situations ....... 18
Section 8 CURRENT STATUS OF OSI IN THE INTERNET ....... 19
Section 8.1 NATIONAL BACKBONES ........................ 19
Section 9 APPENDIX A .................................. 20
Section 9.1 DEFINITION OF ACRONYMS .................... 20
Section 10 REFERENCES ................................. 21
Page 24